Coverage decreased (-0.48%) when pulling e151fcb on laube:fix/commit_where_follow into 7860e50 on gitlabhq:master.

Coverage decreased (-0.48%) when pulling f79fe70 on laube:fix/commit_where_follow into 7860e50 on gitlabhq:master.

@laube is this something you can get working again? Perhaps @woita, @akzhan, and @mr-vinn may be able to help or at least offer tips.

For reference: related to gitlabhq/gitlabhq#3502, gitlabhq/gitlabhq#7417, https://github.com/gitlabhq/gitlabhq/issues/7832, https://github.com/gitlabhq/gitlabhq/issues/6966

I'm not sure we want this in gitlab_git - I agree with @woita in gitlabhq/gitlabhq#7417 (comment) that GitLab should dictate whether --follow is used. This PR would make it impossible to call Commit::where with follow: false

Hmm so do you think the original solution proposed at gitlabhq/gitlabhq#7417 would work.

@bbodenmiller Yeah, I would probably vote to put it in GitLab instead of the gem. But since gitlabhq/gitlabhq#7417 does the same thing as this PR and always uses --follow when a path is given, I think you could make a case for either one.

Ideally I think it would be nice to have GitLab set the option and default to follow: true, but allow the UI/API to override the default. So instead of making --follow dependent on whether a path is given, we could add a follow parameter to GitLab's Repository#commits that defaults to true.

Proposed solution: gitlabhq/gitlabhq#8280